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What  this  talk  is  about? 


1.  Actual  issues  for  Safety-Critical  systems  design 


2.  Why  Model-Based  Engineering  techniques  are  helpful 


3.  How  AADL  can  detect  issues  early  and  avoid  potential  rework 
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Agenda 

Introduction  on  Model-Based  Engineering 

Presentation  of  the  Case  Study 

System  Overview 

AADL  model  description 

Architecture  Analysis 

Conclusion 
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Agenda 

Introduction  on  Model-Based  Engineering 
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Polling  Question  1 

Do  you  know  what  Model-Based  Engineering  is? 
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SLOC  in  thousands 


Safety-Critical  Systems  are  Intensively  Software-Reliant 

Operational  &  Support 
Software 


25,000 


20,000 


15,000 


10,000 


5,000 


0 


24,000 
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Source:  ‘‘Delivering  Military  Software  Affordably”  in  Defense  AT&L 
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Errors  are  introduced  early  but  detected  (too)  lately 

High  Fault  Leakage  Drives  Major  Increase  in  Rework  Cost 

Aircraft  industry  has  reached  limits  of  affordability 
due  to  exponential  growth  in  SIV  size  and  complexity. 


Requirements 

Engineering 


70%  Requirements  & 
system  interaction  errors 


System 

Design 


Software 
Architectural  , 
Design 


80%  late  error 
discovery  at  high 
rework  cost 


<^70%,  3.5%  lx) 


10%,  50.5% 


Major  cost  savings  through  rework  avoidance 
by  early  discovery  and  correction 

A  SI  Ok  architecture  phase  correction  saves  S3M 


Component 

Software 

Design 

Rework  and  certification  is  70%  of  SW 
cost,  and  SW  is  70%  of  system  cost. 


20%,  16% 
5x 


Where  faults  are  introduced 
Where  faults  are  found 
The  estimated  nominal  cost  for  fault  removal 


Unit 

Test 


NIST  Planning  report  02-3,  The  Economic  Impacts  of  Inadequate 
Infrastructure  for  Software  Testing,  May  2002. 

D.  Gatin,  Software  Quality  Assurance:  From  Theory  to 
Implementation,  Pearson/Addison-Wesley  (2004) 


Costly  certification  process  leads  to  high 
percentage  of  operational  work  around. 


Code 


B.W.  Boehm,  Software  Engineering  Economics,  Prentice  Hall  (1981)  Development 
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Many  Errors  stems  from  Architecture  or 

Global  Variable  used  among  different  functions 
Potential  issues:  inconsistent  value] 

Root  Cause:  Architecture  D< 

Use  of  COTS  components  wj 
Potential  imi 


ation 


Timin 


Forced,  bad  values 
policy,  lack  of  analysis 

I  continue  this  list? 
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Why  Model-Based  Engineering  Matters? 

Capture  system  architecture  with  designers  requirements 

Focus  on  system  structure/organization  (e.g.  shared  components) 
Tailor  architecture  to  specific  engineering  domain  (e.g.  safety) 

Validate  the  architecture 

Check  requirements  enforcement  (e.g.  no  global  variable) 

Detect  Potential  issues  (e.g.  interfaces  consistency) 

Early  Analysis 

Avoid  late  re-engineering  efforts  (e.g.  less  rework  after  integration) 
Support  decisions  between  different  architecture  variations 
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Polling  Question  2 

Do  you  already  know  AADL? 
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Architecture  Analysis  Design  Language 

SAE  Standard  for  Model-Based  Engineering 

First  version  in  2003,  actual  version  2.1 
Definition  of  System  and  Software  Architecture 

Specialized  components  with  interfaces  (not  just  “blocks”) 
Interaction  with  the  Execution  Environment  (processor,  buses) 

Extension  mechanisms 

User-Defined  Properties  (integrate  your  own  constraints) 
Annexes  (existing  for  safety,  behavior,  etc.) 
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AADL  Model  Example 


Communication 

Interfaces 
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Architecture  Analysis  Design  Language 


Safety  &  Reliability 

•MTBF 
•FMEA 

•Hazard 
analysis 


Data  Quality 

•Data  precision/ 
accuracy 

•Temporal 

correctness 

•Confidence 


Auto-generated 
analytical  models 


< 

- ^ 

N 

\ 

/ 

1/ 

Real-time  Performance 


•Execution  time/ 
Deadline 

•Deadlock/starvation 

•Latency 


Security 

•Intrusion 
•Integrity 
•Confidentiality 


Resource 

Consumption 

•Bandwidth 

•CPU  time 

•Power 
consumption 
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Agenda 


Presentation  of  the  Case  Study 
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Objectives  of  this  Study 

Learn  Architecture  Modelling  with  AADL  and  the  OSATE  workbench 
Model  a  family  of  systems  with  their  variability  factors 
Analyze  the  Architecture  from  a  performance  perspective 
Discover  Safety  Issues  using  Architecture  Models 
Support  Architecture  Alternatives  Selection 
Illustrate  the  Process  with  a  relevant  case  study 
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Case-Study  Description 

Self-Driving  car  speed  regulation 

Obstacle  detection  with  user  warning 

Camera  detection 
Infra-red  sensor 
Automatic  Speed  and  Brake 

Two  speed  (wheel,  laser)  sensors 
Redundant  GPS 
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Polling  Question  3 

On  what  aspect  would  you  like  to  focus? 
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Case-Study  Objectives 

Help  designers  to  choose  the  best  Architecture 
Best  reliability,  avoid  potential  failure/error 
Meet  timing  and  performance  requirements 
Analyze  Architecture  according  to  stakeholders  criteria 
Try  to  analyze  what  really  matters 
Quantify  architecture  quality  from  different  perspectives 
Latency 

Resources  and  Budgets 
Safety/Reliability 
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Agenda 


System  Overview 
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Functional  Architecture 


21 


Functional  Architecture,  timing  perspective 


Obstable 

Camera 


Image 

Acquisition 

(SOms) 


Obstable 

Radar 


Radar 
Acquisition 
( 1  Oms) 


Obstacle 

Detection 

(lOOms) 


Obstacle 

Distance 

Evaluation 

(lOmsI 

- 7N — 


Emergency 

(4ms) 


Speed 
Threshold 
Computation 
(4  ms) 

7K 


Max  end-to-end  latency  =  900  ms 
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Functional  Architecture,  criticality  perspective 


_ _ i 

Redundancy  Groups  (performs  the  same  function) 
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Deployment  Alternatives 


Alternative  1:  reduce  cost  and  complexity 

Two  processors  and  one  shared  bus 

Potential  interactions  for  functions  collocated  on  the  same 
processor 


Alternative  2:  reduce  potential  fault  impact 

Increase  potential  production  cost  (more  hardware) 
Three  processors  inter-connected  with  two  buses 
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Architecture  Alternative  1 


Reduce  Cost  and  Complexity 

Potential  interactions  for  functions  collocated 

on  the  same  processor 


Time  to 
Obstacle 
Evaluation 


Emergency 

Detection 


Warning 

Activation 


Warning 

Device 


Speed 

Computation 


Brake 

Acceleration 

Bandwidth:  500  kbps 
Acquisition  time:  10  to  30ms 
Transmission  time:  1  to  10  us  per  byte 


50  MIPS 
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Architecture  Alternative  2  Reduce  Fault  Impact 

Might  increase  production  costs 


ECU2 

50  MIPS 
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Agenda 


AADL  model  description 
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Modeling  Guidelines 

Separate  architecture  aspects  in  different  files 


Leverage  AADL  extension  and  refinement  mechanisms 

Capture  common  characteristics,  avoid  copy/paste 
Extend  generic  components 

Use  properties  to  quantify  quality  attributes 

Processed  by  tools  to  evaluate  architecture  quality 
Specify  once,  use  by  several  analysis  tools 

Ensure  Analyses  Consistency 

— —  _  |  Speed  Regulation  Case-Study 

Software  Engineering  Institute  |  Carnegie  Mellon  University  Julien  Delange 

©2014  Carnegie  Mellon  University 


Model  Organization  -  devices 


Generic  components 


Extension  and  refinements 


radar 


1 
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Model  Organization  -  devices  -  textual  model 


device Iradar 
features 

distance_estimate 
-flows 

f0  :  -flow  source  di 

pro 


Component  Name 


out  data  port  speed_regulation : : icd : : distance; 


IS 


od 


=  >  10ms  : 


annex  Er'V2  •[ 

use  types  speed_reg 


Timing  constraints 

(latency  analysis) 


error  propagations 

distance_estirrate  :  out  propagation!  {NoValue,  InvalidValue}j 
-flows 


ef0  :  error  source  distance_estirrate{NoValue,InvalidValue}j 
end  propagations; 


Error  propagations  and  flows 


Types  of  faults 

(all  safety  analysis  tools) 


proj 


pert ies 


**> 

end 


emv2  ::  severity  =>  ARP4761 :: Major  applies  to  distance est  irrate  .  novalue; 

emv2 :: likelihood  =>  ARP4761 :: Probable  applies  to  distance_estimate . novalue; 
emv2 :: hazards  => 

([  crossreference  =>  ”N/A"; 

■failure  =>  "NcValue"; 
phases  =>  ("all"); 

description  =>  "No  information  from  the  Radar"; 

comment  =>  "Error  if  both  the  camera  and  the  radar  does  not  send  any  value"; 

]> 

applies  to  distance_estimate . novalue; 

emv2 :: severity  =>  ARP4761 : :Minor  applies  to  distance_estimate . invalidvalue; 
emv2 :: likelihood  =>  ARP4761 :: Probable  applies  to  distance_estimate . invalidvalue; 
emv2 :: hazards  => 

([  crossref erence  =>  "N/A"; 

failure  =>  "Invalidvalue"; 
phases  =>  ("all"); 

description  =>  "Invalid  distance  sent  by  the  radar"; 

comment  =>  "First  occurrences  of  invalid  data  Should  be  handled  by  the  distance  estimator 


Documenting  the  faults 

(safety  analysis) 


]) 

applies  to  distance estimate . invalidvalue; 
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Model  Organization  -  Interfaces  Specifications 


Data  types  being  used  to 
communicate  across  functions 


Data  size  properties 

(resource  allocation  and  latency  analysis) 


da-ta  gps_posi-tion 
p  no 


[dati 


>ize  =  >  5  3  Bytes; 


data_mode±  :  :  data_r epr esentation  =>  Array; 
end  g p  s_p  osition; 


One  property,  several  analyses 
<=>Ensure  Analyses  Consistency 


dat; 
end  picture; 


ata_representation  =>  enuir; 

=>  ("brake",  )  ; 

ize  =  >  2  bits; 


data  boolean 
p  ro perties 

IdE^E^- 

end 


ize  =>  1  bit; 


5eed_co<nrand 
;peed_conrrrand; 


data  implementation  speed_corrrrand  .  i 
subcomponents 

kind  :  data  speed_comirand_type; 
value  :  data  base_types: :unsigned_16; 
end  speed_conrrrand  .  i; 

data  distance  extends  base_types : : unsigned_32 
end  distance; 
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Model  Organization  -  platform 


ecu  rs232  one  connector 


ecu  rs232  two  c< 

Generic  Processor  Component 

- 

(common  for  all  the  architecture) 

processor  ecu 

properties 

ecu 

SEI: : MIPSCapacity  =>  50.0  MIPS; 

end  ecu; 

/ 

? 

ecu_ca n_one_co n  necto  r 

_ 2 _ 

e  c  u_can_two_con  nectors 

_ 

r 

processor  ecu_can_one_connector  extends  ecu 
■features 

socket  :  requires  bus  access  can; 
end  ecu_can_one_connector; 


bus  can 
properties 


/ - \ 

^  N 1/ 


atency =  >  1  Ms  . .  1  Ms; 

SEI :  :  BandW'idthCapacity  =>  590000.0  bitsps; 
Transmission_Time  =>  [  Fixed  =>  10  ms  . .  30ms; 

PerByte  =>  1  us  . .  10  us;  ]; 


L 


U  Ldn 


Processor  extension,  specify  bus  connections 
Share  properties  of  inherited  component 


Timing  information 

(latency  analysis) 
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Model  Organization  -  software  (1)  AADL  Process 


/radar  acquisition/ 

/  /  / 

^peed_controlle^/ 

A 

i 

i 

• 

• 

i 

i 

1 

1 

a 

a 

i 

a 

£peed_control»er^/ 

t  i  i 

•  it 

t  radar  acquisition  thr^/  t  < 

•  »  t 

'  ' 

peed,  otontroller  thr  # 

/ - ' - 7 

Aadar  acquisition  thr.y' 

L _ t 

image  .acquisition/ 


mage_ac  q  u  is  it  k>n .  ■ 


%  •  w  m  2  "  / 

r !  peed_S»ntroller  thr/  /speed_estirrwite_thr/  /obstacle  detection  thr /image  acquisitionthr, 

i  "  a  *  0 

- _ V _ /  c. _ ... _ J  < _ _ _ _ _ _ / 


/  / 

/speed  estimate  thr.l  / 

/  / 
_ -/ 


L^lmage_acquisit»on_thr.i  / 


AADL  Thread 


One  software  function  =  1  AADL  process  +  1  AADL  thread 
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Model  Organization  -  software  -  textual  notation  (1) 


rocess  radar_acquisition 
eatures 

obstacle_distance  in  data  port:  speed_regulation :: icd :: distance; 


use  behavior 


speed regulation  :  :error library:  :  sin-pie; 


error  propagations 

obstacle_distance  :  in  propagation  -fNoValue, InvalidValue}; 
obstacle_detected  :  out  propagation  {NoValue, InvalidValue}; 
processor  :  in  propagation  {Sof twareFailure ,  HardwareFailure}] 

■flows 

e-f0  :  error  path  obstacle_distance{NoValue}  ->  obstacle_detected{NoValue}j 
e"fl  :  error  path  obstacle_distance{NoValue}  ->  obstacle_detected{InvalidValue}j 
e-f3  :  error  path  obstacle_distance{InvalidValue}  ->  obstacle_detected{ InvalidValueJ ; 
e"f2  :  error  path  processor{Hardv/areFailure,SoftwareFailure}  ->  obstacle_detected{NoValue}j 
end  propagations; 


component  error  behavior 
transitions 

t0  :  Operational  - [processor{SoftwareFailure} ] - > 
tl  :  Operational  -[processor{HardwareFailure}]-> 
t2  :  Failed  - [processor{NoError}] ->  Operational; 
propagations 

pi  :  Failed  -[]->  obstacle_detected{NoValue}; 
end  component; 


Failed; 

Failed; 


Component  type 


Communication  interfaces 


Data  flow  specification 
(latency  analysis) 


Error  specification 

.afety  analyses) 


a  a  a  r  a  c  q  u 


Subcomponents 
and  connections 


1  nrnrpss 

imnlpmpntatron  radar  arnui^iti 

o  n 

subcomponents 

thr  :  thread  radar_acquisition_thr 
connections 

c0  :  port  obstacle_distance  ->  tNnJ 
cl  :  port  thr. obstacle  detected  -W 

/  Component  implementation 

f.  obstacle_distance; 

^obstacle  detected^ 

■  flows 

-fa  . 

XI  «...  na-»-U  nkcfarlc  

^  /-C4   N.  t-kr'  -fC4   /“  -f   N.  cil-ir^a/-l  a  ^ 

end  radar_acquisition . i j 
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Model  Organization  -  software  -  textual  notation  (2) 


thread  radar_acquisition_thr 
features 

obstacle_distance  :  in  data  port  speed_regulation: :icd: : distance; 
obstacle  detected  :  out  data  port  speed  regulation :: icd :: boole 


Data  flow 

(latency  analysis) 


flows 


en 


Resource  Budgets 

(resource  allocation  analysis) 


Time  information 

(latency  analysis) 
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Model  Organization  -  safety  specification 


package  speed_regulatiori  :  :error_library 

public 

annex  EMV2 

^rrol^^ype^ 


Error  types  that  could  be  raised 


No Power 
ValueEr 
N  oVa 1 u e 
Invalid 
Hardwar 
Softwar 
end  types j 


typej 


Error  states 


1  -  dim  e 


L>'Pe  > 


error  behavior  simple 
states 

Operational 
Failed 

end 


j' j 

end  spee 


initial  state; 
state  ■, 


Component-specific  error  transitions 
(to  be  added  on  a  component-basis) 
Keusaoie  error  state  macnmes 

to  be  attached  to  components 
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Model  Organization  -  define  error  flows  -  error  source 


device  camera 
features 

picture  :  out:  data  port:  speed_regulation:  :icd:  :  picture; 
flows 


lF0  :  flow  source  picture 
properties 

Period  =>  200(rs; 

annpM  F. f** 


Reuse  predefined  types 


use  types  speed  £e % u  1  at ionjj^er r^r 

error  propagations 

picture  :  out  propagation  {NoValue}} 


Define  error  types  propagated 
on  component  interfaces 


ef9  :  error  source  picture{NoVakj^^. 
end  p  ro  p  a  gat  io  ns  ; 


=j==fcTi  « 

j  j- 


end  camera; 


Define  the  error  sources, 
what  interfaces  initiates  an  error  flow 


Component  camera 


NoValue  error  propagated 
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Model  Organization  —  define  error  flows  -  error  path 


annex  EMV2  {’ 


use  types 
use  behavior 


speed reguiation :  :  error!ib 
speed  regulation :: error  library: : simple ;  I 


Reuse  predefined  types  and  behavior 


Define  error  types  propagated  on  component  interfaces 


obstacle_distance  :  in  propagation  {HoValue,  InvalidValue  j-j 
obstacle_detected  :  out  propagation  {NoValue.,  InvalidValue}.} 
processor  :  in  propagation  -fSoftv.areFailure .  Hardv.areFailurel ; 


f  lows 
ef0 
efl 
ef3 
ef  2 

end  propagations; 


error  path  obstacle_distance{NoValue}  ->  obstacle_detected{NoValue} j 
error  path  obstacle_distance{NoValue}  ->  obstacle_detected{InvalidValue}} 
error  path  obstacle_distance{InvalidValue}  ->  obstacle_detected{InvalidValue} j 
error  path  processor{Hardv.areFailure, 


c>; 


Define  the  propagations  flows 


obstacle  distance  /  NoValue 


obstacle  distance  /  InvalidValue 


Processor  /  SoftwareError 


Processor  /  HardwareError 


obstacle_detected  /  NoValue 


obstacle detected  /  InvalidValue 


Component 
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Model  Organization  -  error  sink  &  define  component  error  behavior 


device  war ning_de vice 
features 

warning  :  in  data  port  speed_regulation ;;  icd  ::  boolean  j, 
flows 

f3  s  flow  sink  warning; 
p  ro  p  e  rt  i  e  s 

Period  =>  B38ims; 

CfciflLJf-Ti  X  =*==♦= 


Use  predefined  error  types 
and  component  behavior 


use  types 
use  behavior 


;peed_regulation : ; error_library; 
;peed_regulation  :  :  error_libraryi  ::  simple  j 


error  propagations 

warning  :  in  propagation  {HoVa 1 ue , I nva lidVa lue } ; 
flows 

ef6  :  error  sink  wa r n i n g f Ho V a 1 u e , I nv a 1 i dVa 1 ue}; 
end  propagations; 


component  error  behave 


events 


Reset 


Define  component-specific 
error  events 


recover  event 


trans it ion  s 

t3  Operational  -  [warning{NoValue}  ]  -  >  Failed 5 
tl  :  Operational  -  [war ning{In valid Value  )- ]  ->  Failed.; 
t2  :  Failed  -[Reset]- >  Op erationalj 
end  component; 


NoValue 

InvalidValue 


end  war ning_de vice ■ 


Component-specific 
error  transitions 


Software  Engineering  Institute 


Carnegie  Mellon  University 


Speed  Regulation  Case-Study 
Julien  Delange 

©2014  Carnegie  Mellon  University 


39 


Model  Organization  -  architecture  alternatives 


Common  type  for  all 
architecture  alternative 


System  implementation  with 
all  common  components 


Capture  architecture 
alternatives  variability 
(processors,  buses,  etc.) 


i  nteg  rati  on.im  pleme  ntati  on  1 


=  Software  Engineering  Institute 


Carnegie  Mellon  University 


Speed  Regulation  Case-Study 
Julien  Delange 

©2014  Carnegie  Mellon  University 


40 


Architecture  Alternative  1:  model  instance 
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Architecture  Alternative  2:  model  instance 


*  Variability  Factors  with  Alternative  1 
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Agenda 


Architecture  Analysis 
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Latency  Analysis,  results 


Architecture 
Alternative  1 


flow 

model  element 

name 

deadline  or  conn  delay 

total 

expected 

fO:  End  to  End  Latency  report 

fO  (Synchronous) 

device 

obstacle  camerarfO 

200.0  ms 

200.0  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  camera. pictur 

0.0  us 

200.0  ms 

900.0  ms 

fO  (Synchronous) 

thread 

image  acquisition.thrrf 

50.0  ms 

250.0  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

image  acquisition.thr.c 

0.0  us 

250.0  ms 

900.0  ms 

fO  (Synchronous) 

thread 

obstacle  detection.thr: 

100.0  ms 

350.0  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  detection.thr. 

30.00125  ms 

380.00125  ms 

900.0  ms 

fO  (Synchronous) 

thread 

obstacle  distance  eval 

10.0  ms 

390.00125  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  distance  eval 

0.0  us 

390.00125  ms 

900.0  ms 

fO  (Synchronous) 

thread 

emergency  detection. t 

4.0  ms 

394.00125  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

emergency  detections 

0.0  us 

394.00125  ms 

900.0  ms 

fO  (Synchronous) 

thread 

warning  activation.thr: 

2.0  ms 

396.00125  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

warning  activation.thr. 

0.0  us 

396.00125  ms 

900.0  ms 

fO  (Synchronous) 

device 

warning  alert:fO 

500.0  ms 

896.00125  ms 

900.0  ms 

fO  (Synchronous) 

Total 

0.0  us 

896.00125  ms 

900.0  ms 

Architecture  CvO 
Alternative  2  ^b 


flow 

model  elemer 

name 

deadline  or  corn 

total 

expected 

fO:  End  to  End  Latency  report 

fO  (Synchronous) 

device 

obstacle  camerarfO 

200.0  ms 

200.0  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  camera. picture  - 

0.0  us 

200.0  ms 

900.0  ms 

fO  (Synchronous) 

thread 

image  acquisition.thrrfO 

50.0  ms 

250.0  ms 

1 900.0  ms 

[ 

fO  (Synchronous) 

Connection 

image  acquisition.thr.ob; 

o 

o 

c 

250.0  ms 

900.0  ms 

fO  (Synchronous) 

thread 

obstacle  detection. thrrfO 

100.0  ms 

350.0  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  detection. thr.ot 

100.00625  ms 

450.00625  ms 

900.0  ms 

fO  (Synchronous) 

thread 

obstacle  distance  evalualO.Oms 

460.00625  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

obstacle  distance  evaluaO.Ous 

460.00625  ms 

900.0  ms 

fO  (Synchronous) 

thread 

emergency  detection.thr  4.0  ms 

464.00625  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

emergency  detection.thr  0.0  us 

464.00625  ms 

900.0  ms 

fO  (Synchronous) 

thread 

warning  activation. thrrfO 

2.0  ms 

466.00625  ms 

900.0  ms 

fO  (Synchronous) 

Connection 

warning  activation.thr.ac 0.0  us 

466.00625  ms 

900.0  ms 

fO  (Synchronous) 

device 

warning  alertrfO 

500.0  ms 

966.00625  ms 

900.0  ms 

fO  (Synchronous) 

Total 

0.0  us 

966.00625  ms 

900.0  ms 

|ERROR:  fO:  End-to-end  flow  fO  calculated  latency  (Synchronous) 

1  966.00625  ms  exceeds  expected  latenc^^O^^^^J 
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Resources  Allocation  Analysis,  principles 
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Resources  Allocation  Analysis,  results 


Architecture 
Alternative  1 


Architecture 
Alternative  2 
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Safety  Analyses  Overview 

Functional  Hazard  Analysis  (FHA) 

Failures  inventory  with  description,  classification,  etc. 

Fault-Tree  Analysis  (FTA) 

Dependencies  between  errors  event  and  failure  modes 

Fault-Impact  Analysis 

Error  propagations  from  an  error  source  to  impacted  component 
Need  to  combine  analyses 

Connect  results  to  see  impact  on  critical  components 
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Safety  Analysis,  FHA,  results 

Architecture  Alternative  1:15  errors  contributors 


Architecture  Alternative  2:  17  errors  contributors 


Difference  stems  from  additional  platform  components  (ecu) 
Have  to  consider  criticality  of  fault  impacts 
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Safety  Analysis,  FTA  results 

Architecture  Alternative  1:15  errors  contributors 

Architecture  Alternative  2:  17  errors  contributors 

Difference  stems  from  additional  platform  components  (ecu) 
Have  to  consider  criticality  of  fault  impacts 
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Safety  Analysis,  Fault  Impact,  results 

Architecture  Alternative  1  &  2:  443  error  paths 
Use  the  same  paths 

The  additional  ECU  in  alternative  2  covers  path  from  ecu2 
in  Alternative  1 

Impact  on  components  criticality 

Defect  on  the  additional  bus  in  Architecture  2  impact  low-critical 

functions 

Isolate  defect  from  low-critical  functions  to  affect  high-critical 
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Analysis  Summary 


Architecture  1 

Architecture  2 

Latency 

© 

* 

Resources  Budgets 

K 

© 

Safety 

© 

Cost 

© 

X 

What  is  the  “best”  architecture? 
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Agenda 


Conclusion 
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Conclusions 


Safety-Critical  Systems  Development  issues  is  not  a  fatality 

Late  detection  of  errors  is  no  longer  possible 
Need  for  new  methods  and  tools 
AADL  supports  Architecture  Study  and  Reasoning 
Evaluate  quality  among  several  architectures 
Ease  decision  making  between  different  architecture  variations 
Analysis  of  Architectural  change  on  the  whole  system 
User-friendly  and  open-source  workbench 
Graphical  Notation 

Interface  with  other  Open-Source  Tools 
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Useful  Resources 

AADL  wiki  -  http://www.aadl.info/wiki 


Model-Based  Engineering  with  AADL  book 
SEI  blog  post  series  http://blog.sei.cmu.edu 

Mailing-List 

see.  https://wiki.sei.cmu.edu/aadl/index.php/Mailing  List 
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Questions  &  Contact 

Dr.  Julien  Delange 

Member  of  the  Technical  Staff 
Architecture  Practice 
Telephone:  +1  412-268-9652 
Email:  info@sei.cmu.edu 

Web 

www.sei.cmu.edu 

www.sei.cmu.edu/contact.cfm 


U.S.  Mail 

Software  Engineering  Institute 
Customer  Relations 
4500  Fifth  Avenue 
Pittsburgh,  PA  15213-2612 
USA 

Customer  Relations 

Email:  info@sei.cmu.edu 
Telephone:  +1  412-268-5800 

SEI  Phone:  +1  412-268-5800 

SEI  Fax:  +1  412-268-6257 
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